Throttling PostgreSQL's CPU usage

Поиск
Список
Период
Сортировка
От Daniel Griscom
Тема Throttling PostgreSQL's CPU usage
Дата
Msg-id p0624080bc266892a91b2@[192.168.1.8]
обсуждение исходный текст
Ответы Re: Throttling PostgreSQL's CPU usage  ("Steinar H. Gunderson" <sgunderson@bigfoot.com>)
Re: Throttling PostgreSQL's CPU usage  (Bill Moran <wmoran@collaborativefusion.com>)
Re: Throttling PostgreSQL's CPU usage  (david@lang.hm)
Re: Throttling PostgreSQL's CPU usage  (Mark Lewis <mark.lewis@mir3.com>)
Список pgsql-performance
I'm building a kiosk with a 3D front end accessing PostGIS/PostgreSQL
via Apache/PHP. The 3D display is supposed to show smooth motion from
location to location, with PostGIS giving dynamically updated
information on the locations. Everything runs on the same machine,
and it all works, but when I start a query the 3D display stutters
horribly. It looks like PostgreSQL grabs hold of the CPU and doesn't
let go until it's completed the query.

I don't need the PostgreSQL query to return quickly, but I must
retain smooth animation while the query is being processed. In other
words, I need PostgreSQL to spread out its CPU usage so that it
doesn't monopolize the CPU for any significant time (more than 50ms
or so).

Possible solutions:

1: Set the PostgreSQL task priority lower than the 3D renderer task,
and to make sure that the 3D renderer sleep()s enough to let
PostgreSQL get its work done. The obvious objection to this obvious
solution is "Priority inversion!", but I see that as an additional
challenge to be surmounted rather than an absolute prohibition. So,
any thoughts on setting the PostgreSQL task priority (including by
the much-maligned tool shown at
<http://weblog.bignerdranch.com/?p=11>)?

2: Some variation of the Cost-Based Vacuum Delay. Hypothetically,
this would have the PostgreSQL task sleep() periodically while
processing the query, allowing the 3D renderer to continue working at
a reduced frame rate. My understanding, however, is that this only
works during VACUUM and ANALYZE commands, so it won't help during my
SELECT commands. So, any thoughts on using Cost-Based Vacuum Delay as
a Cost-Based Select Delay?

3: ... some other solution I haven't thought of.


Any thoughts, suggestions, ideas?


Thanks,
Dan

--
Daniel T. Griscom             griscom@suitable.com
Suitable Systems              http://www.suitable.com/
1 Centre Street, Suite 204    (781) 665-0053
Wakefield, MA  01880-2400

В списке pgsql-performance по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: DISTINCT Question
Следующее
От: Charles Sprickman
Дата:
Сообщение: Re: Best OS for Postgres 8.2